home *** CD-ROM | disk | FTP | other *** search
/ Whiteline: delta / whiteline CD Series - delta.iso / vision / grafics / programm / ximgtool / ximgtool.ger < prev    next >
Text File  |  1995-11-25  |  11KB  |  247 lines
  1.     Dokumentation zu XIMGTOOL und IMGCODEC-Sourcecode
  2.  
  3.             Stand: Jun 18 1995
  4.  
  5.  
  6. 1. Überblick
  7. """"""""""""
  8.  
  9. Hiermit wird eine Erweiterung des IMG-Formates für Monochrom- und
  10. Farbpalettenbilder vorgestellt. Das Ziel bestand darin, das bekannte
  11. IMG-Pack- und Entpackverfahren so weit wie möglich zu verallgemei-
  12. nern und damit die mögliche Packrate zu steigern, ohne völlig neue
  13. Algorithmen einzuführen.
  14.  
  15. Das Ergebnis ist die Definition von 3 Stufen des IMG-Formates, be-
  16. zeichnet als Level 1, 2 und 3. Level 1 ist dabei der 'Kompatibili-
  17. täts'-Level, also mit dem bisherigen Verfahren identisch. Level 2
  18. und 3 definieren naheliegende Erweiterungen, die so ausgelegt sind,
  19. daβ ein entsprechender Decoder auch die niederen Level ohne Zusatz-
  20. aufwand bearbeiten kann! Ein solcher Decoder wird im Sourcecode
  21. mitgeliefert und ist so ausgelegt, daβ er auf flexible Weise in
  22. Anwendungsprogramme eingebunden werden kann. Das Utility XIMGTOOL
  23. demonstriert die Anwendung sowohl des Decoders als auch der beige-
  24. fügten Encoder und soll als Hilfsmittel für die beliebige Konver-
  25. tierung zwischen den Level dienen. Gleichzeitig mit dem hier ver-
  26. öffentlichten Tool und den Sourcen wird eine neue 1STGUIDE-Version
  27. herausgegeben, die bereits den Level-3-Decoder enthält und somit
  28. zur praktischen Kontrolle der Verfahren benutzt werden kann.
  29.  
  30. Der Effekt der durch die Erweiterungen erreichten Verbesserungen
  31. der Packrate ist unterschiedlich und hängt von der Art der Bilder
  32. ab. Vor allem bei typischen Bildschirm-Snapshots von Desktop-Szenen
  33. oder Linien- bzw. Objekt-Zeichnungen wurden erstaunliche Einspa-
  34. rungen von durchschnittlich 15 %, manchmal um 30 %, erzielt.
  35. Weniger Einsparungen ergeben sich bei Photomaterial, aber auch
  36. dabei können immerhin einige KBytes Ersparnis bei durchschnittli-
  37. chen Motiven erreicht werden.
  38.  
  39.  
  40. 2. Level-Definition
  41. """""""""""""""""""
  42.  
  43. Die Kennzeichnung des Levels einer IMG-Datei erfolgt durch Eintrag
  44. der entsprechenden Nummer als 'IMG-Version' im IMG-Header. Dies ist
  45. das erste Word in der Datei und somit mittels eines Hex-Dumps sehr
  46. leicht zu erkennen.
  47. Bisher stand dort der Wert 1. Dies wird nun als Level-1 interpre-
  48. tiert. Bei einem Level-2 kodierten Image wird hier nun eine 2, bei
  49. Level-3 eine 3 eingetragen. Dies soll hauptsächlich Informations-
  50. zwecken dienen, denn der grundsätzlich empfohlene und mitgeliefer-
  51. te Level-3-Decoder arbeitet unabhängig von diesem Wert!
  52. Manche Programme testen den Versions-Wert ab und warnen den Anwen-
  53. der, wenn dieser Wert gröβer als 1 ist. Das ist korrekt, denn wahr-
  54. scheinlich kommen die Programme mit den hier definierten Erweite-
  55. rungen noch nicht zurecht. Andere Programme (so auch vormalige
  56. Versionen von 1STGUIDE) liefern 'Bildschirmmüll', wenn man mit
  57. ihnen Level-2 oder Level-3 Images lädt.
  58. Ein Programm, welches bisher auf Maximum 1 getestet hat, kann nach
  59. Einbau des Level-3-Decoders einen Test auf Maximum 3 durchführen,
  60. um die 'Gutartigkeit' zu erhalten.
  61.  
  62. Hier folgt nun eine kurze Übersicht über die Eigenschaften der ein-
  63. zelnen Level (Details siehe Sourcecode):
  64.  
  65.  
  66. Level-1:
  67. --------
  68. Kompatibilität, d.h. sollte von allen Programmen, die bisher schon
  69. korrekt IMG-Dateien behandelt haben, verarbeitet werden können.
  70. - Packmethoden auf Planes beschränkt, d.h. weder Plane- noch Line-
  71.   Überschreitung innerhalb eines Packmodus zugelassen.
  72. - vertical replication count (vrc): 1 bis 255 mal Wiederholung der
  73.   aktuellen Zeile.
  74. - pattern run: 1 bis 255 mal Wiederholung eines 'Musters'.
  75. - solid run: 1 bis 127 mal Wiederholung eines 0/0xFF-Bytes.
  76. - byte string: Übernahme der nächsten 1 bis 255 Bytes.
  77.  
  78. Level-2:
  79. --------
  80. - Die Packmethoden müssen nicht mehr auf einzelne Planes einer Zeile
  81.   beschränkt sein. Allerdings darf die Zeilengrenze weiterhin nicht
  82.   überschritten werden.
  83. - Bei vertical replication count (vrc) und byte string wird ein
  84.   0-Byte als 256 interpretiert.
  85. - Einführung des 'extended vertical run mode': Kodierung der
  86.   Wiederholung einer Bytefolge in Bezug auf die vorherige Zeile
  87.   durch erweiterte Interpretation des Zusatzbytes 0xFF beim
  88.   'vollen' vrc. Dies kann als Verallgemeinerung des 'full vrc'
  89.   auf sich wiederholende Teilfolgen einer Zeile aufgefaβt werden.
  90.  
  91. Level-3:
  92. --------
  93. - Hier fällt auch die Beschränkung der Packmodi auf Zeilengrenzen!
  94.   Dank der benutzten ('objektorientierten') Datenstrukturen wird
  95.   jedoch beim Dekodieren weiterhin nur ein einziger Zeilenpuffer
  96.   benötigt!
  97. - Alle genannten Level-2 Erweiterungen gelten hier natürlich auch.
  98.  
  99.  
  100. Die Wirkung der einzelnen Erweiterungen auf die Packrate ist, wie
  101. bereits erwähnt, unterschiedlich. Besonders der 'extended vertical
  102. run mode' ab Level-2 wirkt bei manchen Inhalten angesichts der Ein-
  103. fachheit Wunder, bei anderen bringt er kaum etwas.
  104. Die wegfallende Planegrenze bei Level-2 kann natürlich umso mehr
  105. einsparen, je mehr Planes, also Farben, vorhanden sind. Bei Mono-
  106. chrombildern hat dies keine Auswirkung, hierbei kommen also die
  107. Einsparungen vor allem durch den extended vrc zustande.
  108. Der Fall der Zeilengrenze bei Level-3 bewirkt gegenüber Level-2 mehr
  109. oder weniger geringfügige Einsparungen - im Durchschnitt etwa 1 Byte
  110. pro Zeile, manchmal weniger, manchmal auch deutlich mehr. Probieren
  111. Sie es einfach aus und sammeln Sie damit Erfahrungen!
  112.  
  113.  
  114. 3. XIMGTOOL.TTP
  115. """""""""""""""
  116.  
  117. Hiermit hat man ein Hilfsmittel zur Hand, um ausgiebig die Möglich-
  118. keiten der verschiedenen Verfahren auszutesten und auszunutzen.
  119.  
  120. Aufruf:  ximgtool [Optionen] Input [Output]
  121.  
  122. Optionen:
  123.  
  124.  
  125. -lN:
  126. ----
  127. Benutze Level-N-Encoder, N=1..3. Wird diese Option nicht angegeben,
  128. so wird der Level des Inputs verwendet (eingeschränkt auf 1..3).
  129. Wenn Sie also etwa vorhandene IMG-Dateien (Level-1) maximal packen
  130. wollen, so müssen Sie -l3 angeben. Die so erzeugten Files können
  131. natürlich nur von 'fähigen' (Level-3) Decodern ausgepackt und so-
  132. mit kontrolliert werden, vorerst ist das die aktuelle 1STGUIDE-
  133. Version. Andere Programme werden hoffentlich schnell folgen.
  134. Sie können dies aber trotzdem etwa zur Archivierung der Bilder
  135. verwenden: Mit XIMGTOOL können Sie notfalls die Files wieder in
  136. den kompatiblen Level-1 verwandeln und dann mit anderen Programmen
  137. verarbeiten. Geben Sie dazu -l1 an. XIMGTOOL selbst benutzt grund-
  138. sätzlich den universellen Level-3-Decoder.
  139. Die verwendeten und im Sourcecode vorliegenden Encoder sind bereits
  140. das Ergebnis einer ausgedehnten Optimierungsphase. So erzeugt etwa
  141. selbst der kompatible Level-1-Encoder meist geringfügig kleinere
  142. Files als die bisher effektivsten mir bekannten Programme, nur in
  143. sehr seltenen Fällen gibt es kleine Verluste. Das Optimum bei den
  144. Encodern ist also noch nicht erreicht, hier sind sicher in Zukunft
  145. noch Verbesserungen möglich, während es am Decoder keine wesentli-
  146. chen Änderungen mehr geben kann.
  147.  
  148. -pN:
  149. ----
  150. Erzeuge Output mit pattern run N, N=1..2. Standardmäβig wird der
  151. pattern run des Inputs verwendet (eingeschränkt auf 1..2).
  152. Der pattern run ist eine globale IMG-Variable und läβt sich daher
  153. leider nicht ohne weiteres in einem Pass optimieren. Manche Bilder
  154. erreichen höhere Packraten mit 1, andere mit 2. Da hilft nur Aus-
  155. probieren!
  156.  
  157. -i:
  158. ---
  159. Identifiziere den Input, keine Kodierung.
  160.  
  161. -m:
  162. ---
  163. Mehrfach-Modus (Batch). Als Input kann dann ein Muster mit Standard-
  164. Wildcards angegeben werden. ACHTUNG für GEMINI-Anwender: In der
  165. Console muβ man die Wildcard-Angabe 'quoten', um die automatische
  166. Expansion durch die Shell zu verhindern! Als Output ist ggf. ein
  167. Ziel-Ordner anzugeben.
  168.  
  169.  
  170. Input:  Quelldatei (Muster bei -m).
  171.  
  172. Output: Zieldatei (Ordner bei -m).
  173.  
  174. Nach Bearbeitung wird die Anzahl der Input- und Output-Bytes sowie
  175. die Differenz angezeigt. Letztere ist in der Regel positiv (Einspa-
  176. rung) bei Konvertierung zu einem höheren Level, negativ bei Konver-
  177. tierung in einen niederen Level.
  178. Hinweis: Auch ohne Angabe eines 'Output' wird eine vollständige
  179. Kodierung (dann nur im Speicher) durchgeführt und es werden die ent-
  180. sprechenden Werte angezeigt, was für Testzwecke nützlich sein kann.
  181. Bemerkung: Ein erweiterter XIMG-Header wird von XIMGTOOL in keiner
  182. Weise ausgewertet, er wird direkt in das Outputfile übernommen.
  183.  
  184.  
  185. 4. IMGCODEC-Sourcen
  186. """""""""""""""""""
  187.  
  188. Um eine möglichst schnelle und einfache Verbreitung und Nutzung zu
  189. erreichen, werden vollständige Sourcen für Kodierung und Dekodierung
  190. verfügbar gemacht. Detail-Hinweise entnehme man den eingestreuten
  191. Kommentaren.
  192. Während es, wie bereits erwähnt, am Decoder eigentlich nichts mehr
  193. wesentlich zu verändern gibt, sind an den Encodern wahrscheinlich
  194. noch Optimierungen möglich, wenngleich hier bereits einiger Aufwand
  195. investiert wurde. Es werden alle jeweils verfügbaren Packmodi
  196. genutzt und eine eigene vrc-Behandlung durchgeführt, unabhängig von
  197. den im Inputfile bereits vorhandenen vrc's. Es sollte also für ein
  198. und denselben Bildinhalt immer das gleiche Resultat herauskommen,
  199. unabhängig von der Kodierung des Inputfiles.
  200. Wer einen Beitrag zur Verbesserung der Encoder leisten kann, sei
  201. hiermit herzlichst dazu eingeladen, dies kundzutun und einflieβen
  202. zu lassen. Man beachte aber: Es ist sehr leicht, einen Encoder zu
  203. basteln, der spezielle Inhalte besser packt, dafür aber bei anderen
  204. Daten deutliche Verluste bringt. Es kommt also immer auf das Testma-
  205. terial an, dieses sollte möglichst umfangreich und anwendungstypisch
  206. sein. Erst wenn man eine Routine gefunden hat, die bei typischen
  207. Bildern deutliche Einsparungen bringt und höchstens im Ausnahmefall
  208. geringfügig verliert, kann man dies allgemein ins Auge fassen.
  209.  
  210. Neben den reinen Codec-Sourcen gibt es noch Anwendungsbeispiele
  211. für MFDB-Input und -Output, die als Vorlage für entsprechende
  212. Applikationen dienen können.
  213.  
  214.  
  215. 5. Ausblick
  216. """""""""""
  217.  
  218. In Vorbereitung ist derzeit die Erweiterung des IMG-Formates auf
  219. True-Color-Unterstützung (allgemeiner Direct-Color, es wird auch
  220. High-Color-Modi umfassen). Da die Auswertung und Darstellung
  221. dieser Variante jedoch aufwendiger und umfangreicher ausfallen
  222. wird, sollte zunächst die hier vorliegende Level-Spezifikation
  223. aufgrund des allgemein geäuβerten Interesses unverzüglich ver-
  224. öffentlicht werden. Die TC-Erweiterung wird auch von der Level-
  225. Spezifikation unabhängig sein, ja es kann sogar garantiert werden,
  226. daβ die jetzigen Routinen mit der künftigen Erweiterung ohne
  227. Änderung weiterverwendet werden können, da sich diese Erweiterung
  228. nur auf die Festlegung eines entsprechend erweiterten IMG-Headers
  229. zur Interpretation der Pixeldaten beziehen wird. Die Pixeldaten
  230. selbst werden nach dem gleichen Schema behandelt.
  231. Das XIMGTOOL.TTP wird grundsätzlich auch für die TC-Files benutzt
  232. werden können, da es unabhängig von erweiterten Header-Informationen
  233. und der Interpretation der Pixeldaten arbeitet.
  234.  
  235.  
  236. 6. Bezugsadresse
  237. """"""""""""""""
  238.  
  239. Sachdienliche Hinweise sind jederzeit willkommen und werden dankend
  240. entgegengenommen. Eine vertrauliche Behandlung ist ausgeschlos-
  241. sen ;-). Bitte wenden an:
  242.  
  243.     Guido Vollbeding
  244.     Turmstraβe 61
  245.     [D-]06110 Halle (Saale)
  246.     [Deutschland]
  247.